With the wide acceptance of the Internet and the World Wide Web, it has become much easier for users to access various resources such as documents, directories, databases, web pages and services using Common Gateway Interfaces (CGIs) or Servlets over the Internet. This has given rise to some serious security issues relating to access of data on individual computing resources such as authentication of users, integrity checking of users platforms, privacy and security of data, and authorization to access data.
Known prior art security systems include Microsoft's Cryptographic API (CryptoAPI), which is dependent upon the Internet Explorer 3.x or above and Windows NT 4.0, and the known Sun Microsystems' Java Cryptography Extension (JCE) is similarly platform dependent being based upon a Java platform. Each of these prior art security systems are dependent upon a proprietary operating system or platform. The Intel's prior art Common Data Security Architecture (CDSA) is applicable over a wide range of computer platforms and operating systems. The Common Data Security Architecture provides a flexible and extensible framework allowing software and hardware produced by independent vendors to provide added-in security services in a computer platform environment. The Common Data Security Architecture is an open and industry accepted standard, supporting interoperability between platforms, platform independence and a comprehensive set of security services. Since the Open Group adopted its initial specification in December 1997, CDSA has been widely supported. Referring to FIG. 1 herein, the current prior art CDSA version 2.0 has the following 4 layers:                An applications layer 100        A layered services layer 101, having a set of security services protocols, a language interface-adapter and tools        A Common Security Services Manager (CSSM) layer 102        An add-in security modules layer 103, having facility for a plurality of add-in security modules such as a Cryptographic Service Provider (CSP) modules, Certificate Library (CL) modules, Trust Policy (TP) modules, Authorization Computation (AC) modules and Data Storage Library (DL) modules.        
The application layer 100 has a set of security applications, which are contained in the layer; the layered service layer 101 comprises typically a set of security services protocols such as HTTPS, S/MIME, SSL, or SET; the CSSM layer 102 contains a set of management modules 104-109, a set of integrity services for checking the integrity of modules, a manager of security contexts for security services, and a set of interfaces 110-115; and the add-in security modules layer 103 has a set of user configurable security services modules 116-121 which may be proprietary and vendor-specific, and which can be accessed by the CSSM via the Interfaces 110-115 in the CSSM layer 102.
The security services management modules 104-109 comprise a Cryptographic Service Provider manager 104, a Trust Policy module manager 105; an Authorization Computation module manager 106; a Certificate Library module manager 107; a Data Storage Library module manager 108; and an elective module manager 109.
A limitation with the known Common Data Security Architecture occurs where a set of trust policies are to be implemented in a computer platform. Trust in a computing platform is a particularly important issue where computer platforms are used for electronic commerce, and handle items such as credit card numbers, automated trading programs and general commercial transactions. Trust policies comprise a set of rules which are followed by a computer platform to determine a level of confidence in the integrity of a computer platform which a user of the computer platform and/or other computer platforms interacting with the computer platform may have. For example, a user or a third party computing entity interacting with a first computing entity must have a degree of confidence that the first computing entity has not been compromised by a virus, or has not been tampered with, such that the computer platform cannot be trusted.
In the known Common Data Security Architecture, trust policies may be implemented by provision of a trust policy services module 117. However, these are proprietary and vendor specific. Each different vendor provides his own trust policy module 117, written in a set of semantics which are specific to that vendor. The semantics of a known trust policy module are completely hard-coded by its module developer. The trust policy module users must understand the semantics used by the vendor-specific trust policy module 117, so that for each trusted policy module 117, modification needs to be made to the trust policy module because of the different semantics used between different vendors. Once a trust policy module 117 is released, users are unable to add new trust policies or modify existing ones without using the vendor-specific semantics. From the user's perspective, this is not ideal, since the user may want their own specific trust policies to be enforced in their application domains instead of those policies provided and hard-coded by the vendor. The security infrastructure provided by the prior art CDSA is neither truly generic nor flexible for security and/or trust management.
In the prior art CDSA security architecture, for each trusted policy module, the semantics of a set of trust policies are determined by an individual developer. Different prior art trust policy modules written by different developers have different sets of semantics. A user may wish to change the trust policies to fit more closely the user's business organization. Because the trust policy module uses non-generic semantics, the user must return to the developer who wrote the trust policy module in order to have those changes made using the prior art security system.